In communications systems with voice call features, a user of a device or near a device is often alerted to an incoming call via an indication to the user in audible form such as a tone or ring, in kinesthetic form such as a vibration, or in visual form such as a flashing light. Some communications systems provide devices which alert the user in a relatively non-intrusive manner. However, there are situations when a user may decide not to receive an incoming call. In some communications systems, due to the way in which they operate, an incoming call and its alert can be intrusive and distracting or even dangerous.
In wireless communication systems which provide dispatch services, push-to-talk™ (PTT™) services are often provided. Push-to-talk™ services typically provide walkie-talkie-like functionality or two-way half-duplex voice communication which enables a single user to communicate with another single user (as in a private session) or enables the single user to communicate with a group of other users (as in a group session). When referred to herein, walkie-talkie-like functionality and half-duplex voice functionality are to be taken generally to mean any network delivered voice communication functionality which at any one time is capable of transmitting voice communication from a talking or transmitting party's device to a listening or receiving party's device, but does not simultaneously transmit voice communication from the receiving party's device to the talking party's device, while the talking party's device is transmitting voice to the receiving party's device. Groups can operate in automatic answer mode or in manual answer mode. In push-to-talk™, for a group in automatic answer mode, voice reception is instantaneous, and requires no recipient action. For a group in manual answer mode, before voice reception, recipient action is required to accept or decline the incoming talk request. Situations may arise where automatic communication or a request for communication would be intrusive, and a user may wish to have no interruptions from calls for a period of time. Additionally, the user may wish not to have to take any action to deny talk requests during that period.
In known systems, do-not-disturb (DnD) functionality is provided so that the user's device and hence the user are not disturbed by an incoming call. When this feature is active, no incoming call is offered to the user. DnD also blocks other forms of alerting, such as Message Waiting Notification alerting. Do-not-disturb makes the user inaccessible for call delivery. This DnD functionality is provided for users of half-duplex voice systems and full duplex voice systems, who do not want to be disturbed. This feature is also defined in IS-41-based systems.
In known systems providing DnD such as the Push-to-Talk™ over Cellular (PoC) system (part of the OMA standard), a user typically requests activation of DnD from the user device, which sends a request to a GLMS (group list management server) or similar call processing server to activate a DnD setting resident at the GLMS for the user device. Once the DnD setting has been changed in the GLMS to a state of do-not-disturb, the GLMS stops all subsequent incoming talk session requests directed to the user's device. According to some standards this is accompanied by the GLMS sending a busy indication to the calling party.
In addition to DnD management the GLMS performs access list management. Access lists are used to specify who is permitted or not permitted to establish a PTT™ session with a specific user device. Both a reject list, and an accept list can be stored for a user device, so that calls from specific user devices on these lists are respectively rejected or accepted automatically.
A standard system architecture in which wireless dispatch call management is performed is defined by the OMA (open mobile alliance) standard. Depicted in FIG. 1 is an OMA compliant system which includes push-to-talk™ over cellular (PoC) services. The overall architecture of the known OMA compliant system is generally indicated by reference numeral 100, and includes a known GLMS (group list management server) 110 which manages groups and lists (e.g. contact and access lists) that are needed for the PoC service. Also shown are the BTSs (base transceiver stations) 105,106,107 through which users can access the system. The illustrated example shows four user devices 101,102,103,104 having respective identifiers (ID) 001,002,003, and 004.
The known GLMS 110 provides list management operations to create, modify, retrieve and delete groups and lists, and to provide storage therefor. Data store 120 provides storage for the known GLMS which includes access lists and DnD flags stored by the user device. The data for the DnD flags and access lists are shown in respect of known user devices 101, 102, and 103 in association with IDs 001,002,003. The access list is provided for each known user device (101, 102, 103) and specifies which other known user devices are permitted to reach the respective known user device (101, 102, or 103) over PoC. For example, for user device 101 having ID 001, the access list contains 002,004,006, indicating that the device having these IDs are allowed to reach the user device 101. The known GLMS 110 also stores for each known user device a DnD flag which may either be a “YES” or a “NO” value which dictates whether or not the user device is in a state of do-not-disturb. Each user device's DnD flag and access list helps facilitate management of talk requests directed to that user device.
According to the OMA standard, the user device is permitted to query and set the value of the DnD flag of that user device, but generally is not permitted to directly query or set the value of a DnD flag of another user device.
FIG. 1 depicts a known user device 104 with ID 004 which is sending a group talk request 109 for a session with other known user devices 101, 102, and 103, all of which are part of the group as defined by OMA. The talk request 109 is received and forwarded by the Radio Access Network (RAN) 105 to the known system 100. Once the request is forwarded to the known GLMS 110, DnD Processing 130 and Access List Processing 140 take place to determine if the talk request 109 is forwarded. Since each of the known user devices 101, 102, and 103, has an associated DnD flag of “YES” in the data store 120 of the known GLMS 110, none of the known user devices 101, 102, and 103, are forwarded the talk request 109 which would take place over RANs 106 and 107.
FIG. 2 shows the steps performed by a known GLMS in a known OMA compliant system to manage incoming calls for a user device using the stored DnD flag and access list for that user device. At step 115, the known GLMS receives an incoming talk request specifying the user device as the device being called. In step 135 the known GLMS checks the DnD flag associated with the user device identified in the talk request. If the DnD flag is set to “NO” then processing of the call continues at step 145 wherein the access lists are processed to assess whether the talk request should be forwarded to the user device or not. If the DnD flag 130 is set to “YES” then the talk request is rejected in step 155, and the user's device is not disturbed.